-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add update-signatures command to migrate deprecated signatures #368
Add update-signatures command to migrate deprecated signatures #368
Conversation
Only print update message if sigs were altered
Refactor typing imports and function names
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me, but I have an additional challenge based on your sample output. :)
The old algorithm could actually generate three different signatures for the exact same secret
under these circumstances, when it appeared at the beginning of a line:
- When introducing/modifying the secret (where it could have been prefixed with
+
in error) - When removing/modifying the secret (where it could have been prefixed with
-
in error) - When the secret was adjacent to an unrelated change (and it could appear as part of the diff context, where it would be prefixed with a space)
Note in the last case, the space would not be considered part of the secret (because it is not in the base64 encoding alphabet) and the "old" signature actually is identical to the "new" signature.
Given this behavior, it's probably common that multiple old signatures may collapse to the same new signature (as demonstrated in your example). While this is totally acceptable, I can't help wondering if it is possible to detect the duplication and simply delete the original signature instead of replacing it with a duplicate new signature.
Regardless of technical merit, I also could see a case made for leaving the duplicates anyway in order to reduce confusion when modifying non-trivial configurations.
One additional thought on this very nice piece of work. Could you attach a flag to For convenience, we could have Thanks again for a very timely contribution! |
Maybe |
This is an interesting thought. At the very least we could warn of any duplicates and let the user handle it. Removing them would be pretty trivial - but which one is the correct one to remove? Maybe best to let them decide. |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am happy with these changes once @rbailey-godaddy's comments have been addressed. In terms of documentation, I feel that addition of a new paragraph in upgrading3.rst
explaining the new features and how to use it should be enough.
--update-configuration (default: True) --remove-duplicates (default: True) Fix return type on util.fail function Remove redundant assert Add tests
Make the output messages more similar
Changed the return type of Added 2 flag options to the command: In the case of removing duplicates, the first instance of the signature is kept and the rest are discarded. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is really great work. Many thanks for the contribution, which makes life better for both users and developers!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good stuff!
To help us get this pull request reviewed and merged quickly, please be sure to include the following items:
PR Type
What kind of change does this PR introduce?
Backward Compatibility
Is this change backward compatible with the most recently released version? Does it introduce changes which might change the user experience in any way? Does it alter the API in any way?
What's new?
This pull request addresses the recent deprecation of some signatures which were generated with the leading
+
/-
from the git diff. That issue is documented here.As stated by the deprecation warning, in tartufo v4.X those signatures will no longer be valid.
In an attempt to ease the migration for all parties involved, this command allows for migration with a single command.
The command performs a local scan (we assume the user is scanning locally, this needs to be documented), parses the deprecations from the ouput there, and makes adjustments in the end users tartufo config file.
Help snippet:
Invoked identically to the
scan-local-repo
command, it accepts all the same options as well.tartufo update-signatures .
Usage
I used tartufo itself for testing, and will include my results here.
Prior to updating the signatures tartufo was producing the following deprecations:
Running the command:
After running the command, the pyproject.toml was altered as follows:
Thoughts